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ABSTRACT 


This research concerns information security and 








computer-network defense. It addresses how to handle the 
information of log files and intrusion-detection systems to 
recognize when a system is under attack. But the goal is 
not the usual one of denying access to the attacker but 


providing a justification for deceptive actions to fool the 





attacker. We implemented a simple demonstration of how two 
different kinds of open-source intrusion-detection systems 


can efficiently pool data for this purpose. 
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Ls INTRODUCTION 





In the “information age" the world became a more 
interconnected place. Critical infrastructure, business 
operations, bank operations, military operations, and 


communication systems are totally dependent on computer 





systems that control almost all aspects of life. The 


global network includes faxes, cellular phones, satellites, 








and more than 650 million people connected to the Internet. 





With this scenario, every year the larger software 


corporations in the world, such as Microsoft, SUN, Oracle, 





and Linux Distributors, release a new version of their 
operating systems (OS), service packs, databases, and 
desktop and server applications for all of those platforms. 
Usually security is not the main goal of all of these 


programs and, even if it were, checking the integrity of 





all these millions of lines of code is impossible. 


Added to this is the number of easily available 





"hacker" web sites on the Internet providing tools to 
exploit this ocean of vulnerabilities. A factor urging a 


change in the approach to defending networks is that hacker 








tools are becoming more automatic and no longer requir 
deep knowledge to use them. Only a few minutes of exposure 
could create millions of dollars of losses due to sensitive 


information becoming accessible by the enemy. 











Michael and Riehle suggested in [1] a different 
defending information systems approach: "Tntelligent 
Software Decoys." This approach borrows ideas from military 











strategy. Instead of blocking or fighting attackers as 





soon as they are detected, a decoy system tries to keep 


them occupied by making them believe that the assault is 





successful and progressing as expected. To do this, we 





must decide how to detect the intrusion, how to respond to 


this attack, and how to implement decoy capabilities. 





Implementing a complete decoy system is out of the 


scope of this research. Therefore, th xperimental design 








that we developed is only a proof of concept. It shows how 





to coordinate an intrusion-detection system with software 
decoys and how to improve the performance of software decoy 
application with an intrusion-detection system. Our 


research is based on familiar defense concepts like 








defense-in-depth, intrusion-detection architecture, secur 


log files, data reduction, the principle of least 




















privilege, and reference monitor. In Chapter we will 





define these concepts. 














Chapter will propose a design that is capable of 








integrating messages read from log files, alerts read from 


the intrusion-detection alert file, and messages read from 











all devices installed to protect our system. It borrows 
some principles from real war strategies, including 
integration of a diversity of resources to provide more 


flexibility. 











Chapters IV, V and VI will show th xperimental 
design architecture, the data collected from this 
experimentation and the analysis of the gathered 


information. As we built the design based on open-source 





applications, we developed installation guidelines, which 
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are included in the appendices, answering one of the most 
important objections to open-source: the lack of good 


documentation. 
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II. BACKGROUND AND DEFINITIONS 


A. SOFTWARE DECOYS 


Since in ancient times Sun Tzu [2] wrote that ‘all 


warfare is based on deception”, deception has a very 





important role in warfare. Dunnigan started his book [3] 





saying, “The most potent weapon in any soldier’s arsenal is 





deception.” Deception is an art supported by technology 


that, when successful, can have a devastating impact on 





victims. Cohen [4] suggests two way of defeating an enemy 


in attacks on computers ("information warfare"): have an 





overwhelming force of some sort (be faster, smarter, better 











prepared, better supplied, first to strike, better 


positioned, and so forth), or manipulate the enemy into 








reduced effectiveness by inducing misperceptions that cause 
the enemy to misuse their capabilities (1l.e., use 


deception). 





In conventional war, the nine main deception types 





defined by Dunnigan are: concealment, camouflage, ruses, 
demonstrations, feints, false and planted information, 


lies, displays and insight. From this list, Neil Rowe [5] 





explained that only the last 3, lies, displays and insight, 


are potential defensive tactics for cyberspace. 





Appropriate deceptive tactics depend on the value of the 
resources being protected and the danger of the attack [6]. 
However, the general idea is to limit or confine attacks 


that get through the first line of defense rather than stop 








them. Deception differs from honeypots [7] by providing 


defense not data. 











Deception could be one more layer in our defense-in 
depth, thus confusing an attack plan for a while. Clearly, 


in the nanosecond computer world, minutes can be a long 





period of time. Delays give time to win race conditions 
against the attacker’s automatic tools, permitting the 


analysis of the attack and a plan to respond. 





Before responding to an attacker or outsmarting them, 


the system must detect the attacker. Thus deception 








capabilities must be integrated in the defense operations. 
This would start with a monitoring system, which is 


described in the next item. 


Thinking about the relationship between time and 





defense, Winn Schwartau in [8] suggested a formula (P > D + 
R) for a security model. He says that if the time value 


afforded a system by protection (P) is greater than the 





amount of time it takes to detect (D) and respond (R) to an 


attack then a secure environment is evident. A system with 





deception (C) suggests a new formula: P + C > D+ R. This 


gives us a quantitative justification for deception. 


Intelligent software decoys [9], has both a protection 





and counterintelligence component. The decoy consists of 
one or more software wrappers placed around a unit of 
software (€.g., component or method), with each wrapper 


consisting of a set of rules for detecting and responding 





to suspicious behavior. Instead of indicating to the 


attacker that he has been detected, the cecoy keeps the 








attacker occupied by creating the illusion for the attacker 





that the attack is progressing as expected, using 





techniques ranging from fake error messages to redirecting 
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the interaction with the attacking computer process to a 


virtual sandbox. 





The goal is threefold: to gather information about the 
nature of the attack, adjust the system’s defenses based on 


the intelligence information, and cause the attacker to 





xperienc an opportunity cost (EF 55 waste attack 





resources that could have been better applied, or expose 


sources and methods). 


B. LOG FILES 


Log files and intrusion-detection systems provide our 


monitoring mechanisms for a computer operating system. Log 





files are defined as files that contain messages about the 





system, including th kernel, services, and applications 
running on it [10]. Today all operating systems, 
applications, and network devices have the capability to 
log information and events that occurred in their 


environment. Thomas A. Wall wrote in [11] that the better 





the log stream, the pattern library, and the analysis 





tools, the better the overall security. He also defines 





two goals of a monitoring system: reducing the likelihood 
of an attack going unlogged to as close to zero as is 


affordable, and increasing the likelihood that the events 





logged for an attack will be recognized as an attack to as 
close to 100 percent as is affordable. He also discusses 
the shape of a logging system, the areas to be logged, the 
logging mechanisms, the logging system design, log 


management, and log analysis. 





In an ideal network, the system log records every 
event. This approach is technically very difficult, as few 


systems have the resources to store all this information. 





Another difficulty is the human incapacity to check 


thousands of lines of information of many log files to 








figure out what is happening. Therefore the log system is 





configured to reduce this ocean of information by recording 
only events necessary to detect known common attack 
patterns, events necessary to detect unusual patterns of 
access, and information about the continued trustworthiness 


of the logging system. 





Different log files keep different information. For 
example, there is a default system log file, a log file for 
security messages, and a log file for kernel events. Some 


log files are controlled by a daemon called syslogd. In 





our experimental design based on the Linux platform we will 
use syslog. A list of log messages maintained by syslogd 


can be found in the /etc/syslog.conf configuration file. 





Syslog is the primary logging mechanism for most Internet- 





related equipment and the most common network logging 





mechanism in the TCP/IP world. Syslog runs on all 





Unix/LINUX systems, and on many other operating systems, 





including Windows platforms that have adaptors. 


The log files that we used in our experiments are in 





the /var/log directory. Most log files are in plain text 








format. In our experiments, we will use a Perl script to 








read this text and do data reduction. In addition we can 
use any text editor or logviewer to inspect the information 


as shown in Figure 1 [10]. 
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Cc. PERL SCRIPT - THE LOG MONITOR 


A log monitor is a process, or daemon, which monitors 


log messages produced by the computer system and programs 


running on it [12]. A properly designed log monitor can 


recognize unusual activity (or inactivity), alert 


administrators to problems, gather statistics about system 


activity, or as in our research, act as the main source for 


the system to take automatic action against a threat. 


A log monitor is an agent, which responds 


automatically to conditions revealed by one or more system 


log messages. The response may consist of autonomous 


to handle a situation and/or notification of a 
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actions 





human administrator. A stateful log monitor is one that 





infers the presence of a condition requiring attention by 





compiling data from more than one log message. Our 
experiments used a stateful log monitor implemented by a 


Perl script. 


Log monitoring requires string manipulation, and Perl 


has features that make it one of the most powerful 





languages for string manipulation. Lutz Prechelt [13] 





tested 80 implementations of the same set of requirements 
and compared some properties, such as run time, memory 
consumption, source text length, and the amount of effort 
required to write them. The results indicate that for the 
given programming problem, which regards string 
manipulation and searches, a “script language” such as Perl 


is more productive than “conventional languages” such as C, 





C++ and Java. In terms of run time and memory consumption, 








“script languages” often turned out better than Java and 


not much worse than C and Ctt. 


For future implementations of deception capabilities, 





Perl is also flexible in implementing rules, reading 





configuration files, reading streams from networks, 





implementing servers and sockets and manipulating a 


system’s call. Others Perl advantages include: 





e Provides features necessary for large projects 





like modularization and object-oriented techniques. 


° Provides great flexibility for manipulation of 





strings using regular expressions. 
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e Allows the use of all system calls including 





those necessary for network tasks. 





° Provides a way to dynamically load a module 


including code written in C. 











D. INTRUSION-DETECTION SYSTEMS 
Intrusion-detection systems (IDSs) are important 
software tools. [14] and [15] provide some background. 


Some useful definitions: 








° Intrusion: Any set of actions that attempt to 
compromise the integrity, confidentiality, or 


availability of a computer resource [14]. 








° Intrusion detection: The problem of identifying 


actions that attempt to compromise the integrity, 





confidentiality, or availability of a computer 


resource [14]. 


e Monitored system or system: Program, application, 
host or a network of computer resources that is being 


monitored [14]. 





° Intrusion-detection systems: Systems that collect 
information from a variety of system and network 
sources and, then, analyze the information for signs 
of intrusion (attacks coming from outside the 


organization) and misuse (attacks originating inside 





the organization) [16]. 
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Crosbie and Spafford in [17] identified desirable 


characteristics of an intrusion-detection system: 





e It must run continually with no human 


supervision. 























e It must be fault tolerant. 
e It must resist subversion and monitor itself. 
° It must impose a minimal overhead on the systems 











where it runs. 





° It must be as “quiet” as possible, precluding 





professional attackers from realizing that they are 





being monitored. 





e It must be configurable and expectantly adaptable 
to changes in the system and to user behavior over 


time. 





e It must be able to detect unknown attacks as much 





as possible without generating a lot of false positive 


and false negative. 





° It must be able to avoid the situation of being 


used as a denial of service mechanism. 





° It must report and launch automated decoy 


Capabilities as soon as possible after an intrusion or 





an attack detection. 
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Intrusion-detection systems can be classified by their 








data collection mechanisms. We can classify IDSs as direct 











or indirect [14]. Indirect IDSs could be sub-classified 
into network-based or host-based with direct data 


collection mechanisms being sub-classified into internal or 





external. Table 1 clarifies these definitions. 








Data Collection Mechanisms 


Host—based Host—based Network-based 
[internal [—s External ——S—s—‘“C;73«@SStSt”t*é<=<‘“CS;CCCS? 


Table 1. Data Collection Mechanisms 














Internal IDSs are those whose code is incorporated in 





the monitored system. We will use both, internal and 


external, in our experimental design. 








Indirect monitoring is the observation of a component 





through a separate mechanism or tool. Direct monitoring is 





better than indirect for many reasons [14]. An intruder 








could potentially alter data from an indirect data source 








before the log monitor uses it, or it could be affected by 





non-malicious failures. But the majority of IDSs use some 








form of indirect monitoring. In our experimental design we 


will use both direct and indirect. 














Network-based IDSs (NIDSs) is the acquisition of data 


from the network, usually done by capturing packets as they 














flow through it. Host-based IDSs (HIDSs) process data that 





originates in computers such as event log files. Network- 








based IDSs capture and analyze TCP/IP packets, and host- 











based IDSs process event logs from operating systems, 





kernels and applications. In our experimental design, we 
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will use both a NIDS and an HIDS. Table 2 [15] summarizes 








the advantages of NIDSs and HIDSs. 














=a Network-based IDS Host-based IDS 


Can watch the whole Can prevent and log abuse of 
network or any subsets privilege attacks. 

of the network from one Can detect elevated privileges 
location. attacks. 

Can monitor and detect Can detect for critical data 
network attacks (e.g., access and modification. 
probes, scans, malicious 

and anomalous activity 

across the whole 

network. 





HAMDPHAYP IO pp 


Can become “invisible” 

for access. 

Can not detect host Can not trace network activity. 
activity. Can only work on specific 

Can not scan protocols platform. 
or content if network Can interfere with implemented 
traffic is encrypted. service activities running in 

Can cause monitoring and the host. 
detecting to become more Can not totally trust the host 
difficult on modern information, once the machine 

switched network. is compromised. 

Can lose some packet 

when working in high- 

speed network. 











HQANPHAS|PIOPHHY 





Table 2. HIDS and NIDS Comparison 


























An increasing number of hybrid IDSs use both HIDS and 





NIDS components to augment the information collected and to 











better analyze it. Such hybrids are better able to provide 








tamper-proof operation. If an attacker tries to use the 





network to launch the attack, they would be monitored; if 





they launched an attack from the machine, they would also 


be monitored. 
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E. LIDS (LINUX INTRUSION-DETECTION SYSTEM) 

















In our experiments we used LIDS [18] as our HIDS. 








LIDS provides protection to file and running processes and 








uses a security kernel. Additionally, LIDS has a built-in 








portscan detector, which can be used to alert users to the 
warning signs of a possible intruder, and can send e-mail 
to the network administrator when a rule is broken. These 


features could be considered response mechanisms and could 





be used to launch decoy capabilities. 








Besides this, the most important feature of LIDS is 


its implementation of the reference monitor concept. A 











reference monitor [19] is an abstraction that allows active 





entities called subjects to mak referenc to passive 





entities called objects, based on a set of current access 
authorizations. Subjects are processes executing in a 
particular domain in a computer system. A domain of a 


process is defined as the set of objects which the process 





currently has the right to access according to each access 


mode. 


As described in [20], a security kernel is the only 


method proven to b ffective at countering the threats of 





penetration and subversion of mechanism; therefore it is 





the only effective method of preventing illicit access to 





information under protection. A security kernel is defined 
as the hardware and software that implements a reference 


monitor. Files, records, and other types of information 





repositories can be built from primitive objects (read and 





write), but access control is provided by the referenc 


monitor on the basis of these primitive objects over which 


Ee) 


it has total control. With regard to information warfare 
in particular, every security feature must itself be 
protected so that they can detect and respond. This 


requires a kernel. 


Previous work of our project implemented a deceptive 








component [21] with security based on kernel modules. LIDS 


works in the same way by improving Linux security at kernel 





level. The main advantage of this solution over NAI 








Wrappers [22] is that LIDS is more comprehensive in its 











kernel capabilities. In Tal DS; the “root” (system 





administrator) is no longer all-powerful. Some files, 














directories, and processes protected by LIDS cannot be 
modified even with the root password. The advantage is 
that even if a vulnerability were found in a program that 


is running with root privilege, the damage of its 





exploitation would be limited. 


F. SNORT - A NETWORK INTRUSION-DETECTION SYSTEM 








Snort is an open-source free NIDS developed by Martin 





Roesch [23]. In early 2002, Snort was downloaded over 
10,000 times a week to protect government, corporate, home, 
and education sites. Snort is small at 1.8 Mbytes in the 
last version (1.9), and extremely configurable, allowing 


users to create their own rules or even reconfigure its 





base functionality though its plug-in interface. The 


schema in Figure 2 shows how Snort works [24]. 
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Packet Decoder 


Preprocessor 
(Plug-ins) 







Packet Stream 





Data Flow 


Detection Engine 
(Plug-ins) 


Output Stage \ 
(Plug-ins) Alerts / Logs 


Figure 2. Snort principle of function 


Figure 2 shows how the packet is sniffed off the 





network interface and passed to the packet decoder where it 





is partitioned into its layers. If any preprocessors have 





been defined, they act upon the packet. Preprocessors 


allow Snort to examine and manipulate network traffic data 





in several useful ways, such as in IP defragmentation, TCP 
stream assembly, portscan detection, and web-traffic 


normalization. The preprocessor can maintain state over 





multiple packets to be more intelligent in its processing. 








Then the packets are passed to the detection engine wher 


rules examine the processed packet. Snort's official 





documentation [25] gives details of rule capabilities. If 








an alert or logging is triggered by the rules, the packet 





is passed to the output preprocessor for appropriate 


processing. 


There are three basic modes of operation in Snort: 











sniffer, packet logger, and NIDS. Each is well suited for 
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a particular traffic analysis task. In our experimental 





design we used Snort in network mode, where it was loaded 
with a configuration file (snort.conf) containing run-time 


directives and rules. Also, a Snort packet can be either 





binary or plain text. For speed and portability, it is 


best to log to a binary-format file, although we used plain 





text in our experiments. 


G. RESPONSE MECHANISMS OR COUNTERMEASURES 


The concept of active response mechanisms or 








countermeasures in an IDS [26] is a form of the idea of 








having the IDS capable of automatic reactions to threats. 
The goal is to prevent further compromise between the 
attacker and the attacked machine. The following 


techniques can be used: 


e RST emission 

e Firewall update 

° Routing table update 

° Signature-based firewall 





An IDS has two parts, data collection and attack 











response. Data collection is done by sensors that are 





usually self-contained detection engines, which obtain 
network packets, search for patterns of misuse, and then 
report alarms to a data-analysis central command. This 


approach does have some problems, however, such as 





difficulty in recognizing denial of service attacks and the 
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creation of race conditions between a packet generated by 








IDS and the packets send by an attacker [27]. 


Automated response to intrusions has become a major 


issue in defending critical systems. Since the adversary 





acts at computer speeds, systems need the capability to 








react without human intervention. An infrastructure that 


supports the development of automated response must allow 





easy integration of detection and response components to 





nabl xperimentation with automated response strategies. 


19 





TH 


IS PAGE 








NTENT 





ONALLY LEFT BLANK 





20 


III. IDS AND SOFTWARE DECOY ARCHITECTURE 


A goal of our research is to show that the integration 














of a NIDS and a HIDS could facilitate deployment of a 


software decoy. But when we started our research we were 














not sure how modular NIDSs and HIDSs could be, which is a 


necessity when integrating them with additional complex 





modules for deception. We discovered one simp] interfac 











that allowed for considerable modularity was to process log 











files created by the NIDS and HIDS, and make this the input 








to the deception processing. 





Ay, INTRUSION-DETECTION INTEGRATION 
Th xperimental design contains two types of 
intrusion detection, NIDS (Snort) and HIDS (LIDS). Another 























module is a log monitor that collects information from 


NIDS, HIDS, and the kernel log file, and then does data 














reduction. Figure 3 illustrates this. As discussed in 























Chapter , good IDSs should provide internal direct data 








collection mechanisms such as those provided by a HIDS. 








Nonetheless, a NIDS with its indirect collection is 














valuable as it can anticipate the attack and the reaction. 





Most attacks start with a probe and scanning and, as seen 








in Table 2, these can only be caught by a NIDS. 








Furthermore, NIDS can see malicious network behavior in a 














variety of forms that a HIDS cannot see. A HIDS can see a 








portscan, but a NIDS can see the similar attacks on other 


sites that happened first. 
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DATA 





REDUCTION 
Figure 3. Architecture schema 
B. IDS AND SOFTWARE DECOY ARCHITECTURE INTEGRATION 
1. How NIDS Can Improve a Software Decoy 


Georgios Fragkos [21] selected an exemplar of attack 





and created a deception for it by using NAI’s Generic 
Software Wrapper Toolkit [22] to do both detection and 
decoying. But his deception ends when the attacker tries 


to interact with the shell since the shell's functionality 





is not being simulated and the attacker will immediately 





discover that something went wrong. Since it is thought 
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that professional attacks always will use automatic tools 


as rootkits, this kind of decoy may only b ffective for a 





few seconds. An alternative could be to transfer the 








attacker to a safer machine wher verything is simulated, 


such as a honeypot or sandbox, where it would be hard for 








the attacker to tell that he is being fooled. 








NIDS can anticipate the attack, thus improving the 


performance of the software decoy application. For 








instance, after NIDS detects a ping it could lie to the 














attacker and send an ICMP (Internet Control Message 
Protocol) message saying “host unreachable”, or the 
software decoy could delay the ping response. Or NIDS 














could incorrectly inform the attacker as to which ports are 


open and what vulnerabilities they have. 


2. How HIDS Can Improve Software Decoy 





After the attacker has gained some privileges on the 


target machine, data collected from the logs would decrease 








in importanc becaus th network information could no 





longer be trusted. The attacker could also launch some 


cryptographic channels to communicate with the outside 








world, making the network analysis more difficult. The 


system developed in our experiments tried to deal with this 





Situation by creating one more layer of defense and one 


more chance to fool the attacker, the layer above the root 











discussed in Chapter (see Figure 4). 
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Root and unprotected world 


LIDS protection for software decoy, log files and all important 
files - Reference Monitor enforcement 


Kernel and 


process to be 
protected 











Figure 4. Inner layers of defense-in 


As seen in Figure 4 above, the root is no 


depth 


logger the 


last level to be attacked to reach the control of the host. 


Even if the attacker gains root privileges, we keep the 











kernel sealed, the process and services untouchable, and 
the decoy programs running. This design minimizes the 


threat to the target system and provides more time for 


launching decoy capabilities against the enemy, which 








increases the deception factor in Schwartau formula [8]. 


3. Data Reduction 


Few systems have the resources to 


store all 


[In a medium 





information generated by various log files. ] 




















network the hard disk could be filled by log file 
information in a few weeks. Tf the log systems are 
concentrated in one machine or file, this situation is much 





worse. Not concentrating all information in on 


file is not reasonable either, as this 





e system or 


situation 





xacerbates the human incapacity to check thousands of 
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lines of information of many log files to figure out what 
is happening. To make a realistic analysis of the 


information collected by some log files, the system 





administrator would have to check each line of each log 





files, comparing timestamps of the events generated by the 





all log files or alert files. 





Therefore, the best solution is implementation of a 





log monitor to reduce this ocean of information by, based 


on a security policy, recording only those events necessary 





to detect attack patterns and events that are suspicious. 


The other advantage is that the log monitor works as an 





interface between the detection and the response. To do 











this work we used Perl as best explained in Section =i 
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IV. EXPERIMENTAL DESIGN IMPLEMENTATION 


We now describe in more detail an implementation of 
intrusion-detection systems to support software decoys. 


The next sections will more thoroughly describe the 





implementation of each module in Table 3. 


Modules 


Defense [DS 
IDS as HII 
Kernel Log 





























Network decoy 
f) Host decoy 








Table 3. Experimental Design Module Implementation 





The modules were implemented for a Linux Red Hat8.0 


platform. This platform was chosen because the source code 





is available, which facilitates instrumentation of the 








kernel. This feature is very important for the 














implementation of LIDS (HIDS) as it works as a patch of a 
“pure” Linux kernel, mandatory in the recompilation of the 


kernel. Another advantage is that the kernel 





instrumentation capacity can facilitate future work as the 





software decoy implementation can also be embedded in the 


operating system kernel. 
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A. EXPERIMENTS 


As a proof of concept, we tested both a network-based 
attack and a host-based attack in experiments. Figure 3 


shows what was implemented. We installed two services in a 








protected host: a Web servic (Apache2.0) and a SSH 





service. The SSH server is part of Red Hat 8.0. In the 








installation of both services the default configuration was 





used. The simulated attacks tried to break into the 


protected host to exploit vulnerabilities of a Web and SSH 





service. 


Most attacks are initiated with footprinting, followed 
by probes and scans. These first steps have the main goal 


of discovering open ports and known vulnerabilities thus 





finding the best way to break into the target host [32]. 








In the first part of an attack the invader bases his action 








on the network environment, so NIDS could better monitor 








the invader's actions. In the second part of the attack, 


after the invader had obtained some privileges, the kernel 








Log Files and HIDS alerts becom ssential for attack 





detection and analysis. 


As described in arlier sections, the Perl script 





(Appendix A) reads the alert file generated by Snort, reads 





the log file generated by Linux kernel and reads the log 








file generated by LIDS, writing in a file called decoy.log 





information about the security policy (Table 4), timestamp 





and IP address. This experiment had the rules shown in 


Table 4 for its security policy. 
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Attacker Detection by Defense Decoy System Reaction 


NIDS ] Log monitor records the action to 
a data reduction file; 
Starts a program to simulate false 
ports; 
Delays the response. 


SCAN NIDS and HIDS | LYING Log monitor records the action to 
a data reduction file; 





Responds with false ports as open; 


Changes the configuration of the 
border Cisco router, redirecting 
the attacker to a fake server. 
CONNECT NIDS and ] Log monitor records the action to 
(LOGIN) Kernel Log a data reduction file; 
File Launches fake xterm. 

BAD ] 1) Log monitor records the action to 
ACTIONS a data reduction file; 
}) Reports login. 

















Table 4. Experiment Security Policy 





1. PING 


Following Table 4, we prepared our environment to 
detect any kind of "ping" (attempt to query the status of 


our protected machine). From an attacker machine 





(192.168.0.1), we started to ping the protected host 
(192.168.0.3). 























e Snort: We wrote a rule to detect any ICMP (Internet 


Control Message Protocol) packet that has a 





destination of the protected host: 


Alert icmp SEXTERNAL_NET any -> SHOME_NET any (msg:”ICMP 





Packet to Protected Host”; classtype:bad-unknown; ) 


To do this, in the snort.conf (see Appendix C) we 


defined SEXTERNAL NET as any IP number but the 











protected host was assigned IP number 192.168.0.3. 
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The SHOME_NET is the protected host [25]. This rule 





generated the following message at the alert file at 





/var/log/snort directory for each ping: 


02/23-15:16:33.464600 LO. [1:0:0] ICMP Packet [RR] 


[Classification: Potentially Bad Traffic] [Priority: 2] {ICMP} 
192.168.0.1 -> 192.168.0.3 





e LIDS: Not involved. 
e Kernel Log File: Not involved. 


e® Log Monitor: Read the alert file, searching for a 





/PING/ pattern. After matching the PING string at 








alert file, the Log monitor recorded in decoy.log: 


HONESTY: hacker(192.168.0.1) PING DEST:192.168.0.3 at 02/23 





15:16:33.464600 2003. 


2. Scan 


Using Win?Map, a well-known scanner, from 192.168.0.1 





(the attacker machine), we scanned the target protected 





host (192.168.0.3) (see Figure 5). 
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Figure 5. Win?Map application scanning the 
target machine 


° Snort: The scan is logged by the Snort portscan 


preprocessor [30]. It records an alert in the 





scan.log file and in the alert log file, both in the 





/var/log/snort directory. Stream4, another 


preprocessor, also logged this activity in the 
/var/log/snort/alert file. This is the output of that 
£2 Le. 


02/24-11:27:29.905403 [**] [117:1:1] (spp_portscan2) Portscan 
detected from 192.168.0.1: 1 targets 21 ports in 0 seconds [**] 
{TCP} 192.168.0.1:60517 -—> 192.168.0.3:506 


02/24-11:27:31.586498 Basa) FED OSL] (spp_stream4) STEALTH 
ACTIVITY (NULL scan) detection [**] {TCP} 192.168.0.1:60525 -> 
192.168.0.3:80 





The portscan preprocessor is a powerful and flexible 





scan detector. It checks for TCP connection attempts to 





more then P ports in T seconds, and UDP packets sent to 


more than P ports in T seconds [25], where P and T are 
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given in the snort.conf file. This portscan can also 





detect a single “stealth scan” packet as in NUL, FIN, 





SYNFIN, and XMAS scans. Another benefit of portscan is 


that alerts only showed once per scan, rather than once per 








packet, which reduces the amount of redundant information 





in the alert file. 


The stream4 preprocessor provides TCP stream 
reassembly and stateful analysis capabilities for Snort. 


Stream4 also gives users the ability to track more than 256 





simultaneous TCP streams. Stream4 should be able to scale 
to handle 32,768 simultaneous TCP connections in its 


default configuration. 


° LIDS: LIDS can also detect port scans when its 
optional port scan detector is enabled. Here is an 
example from its message log file. 


Feb 24 11:19:39 LIDS kernel: LIDS: (undetermined program) pid 0 


ppid 0 uid/gid (0/0) on (null tty): Port scan detected: 
192.168.0.1 scanned 1153 closed ports including 575 ports < 1024) 





° Kernel Log File: Not involved. 


° Log Monitor: Read the alert fil generated by 





Snort, searching for /spp_portscan2/ or /spp_stream4/ 
patterns. After matching one of these patterns at 
alert file, the log monitor recorded in the decoy.log 


fakes 


LYING: hacker (192.168.0.1) SCAN DEST:192.168.0.3 at 02/24- 


11:27:29.905403 2003. 











The Log monitor also read the kernel message log file 








generated by LIDS and generated th following record in 





decoy.log file: 
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LYING: hacker(192.168.0.1) SCAN DEST:192.168.0.3 at Feb 


11:19:39 2003. 





3. Connect 


In our scenario, see Table 4, after a ping and a scan 





the attacker tries using the PuTTY application (Figure 6) 








to connect to the target machine at port 22 (ssh). 


Sn PuTTy Confquretion 


Corny cx 
[= Sessan Bass cottons tir pour Puul TY ception 
»D Spenly you conmecton by hart ners or F adders 
— Host Nawne or  oddesa| _ Pot 
Keybood Gao iano 3 R 
Eel 
Protos : - - 
C Pee © Tere © filbgn © 55H 


Lood. eave 0 Cebete 2 Mored tenth’ 


Saved Sera: 








Deteed Setteg: Loed 








Bus Cire verdow on ent 
=  Absps © Never © Oni onckssn ext 





thor Oren Cancel 


SSH connection from attacker 
machine 


Figure 6. 


After that, for experimental purposes only, the 





attacker logs in as root (Figure 7), simulating that the 


root password was previously known. 





Figure 7. Attacker login 
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° Snort: Snort was configured to detect any attempt 








to telnet or to connect using the protocol SSH against 





the protected host. These are the rules: 





alert tcp SEXTERNAL NET any -> STELNET_SERVERS 23 (msg: "TELNET 
attempt"; flow:to_server,established; classtype:shellcode-detect; 
sid:1430; rev:5,;) 








alert tcp SEXTERNAL NET any -> SSSH_SERVERS 22 (msg: "SSH 
attempt"; flags:St; classtype:suspicious-—login; sid:1431; rev:5,;) 





These rule configurations use the variable 








SEXTERNAL NET defined in snort.conf as being any host but 





the protected host (192.168.0.3). Both TELNET_SERVER and 








SSH_SERVER are defined as being the protected target host, 
LOD 16:8... 0:53). 





Due to the encrypted nature of a SSH connection, 
detecting such an attacker's attempt to scale privileges is 


impossible. But we can detect whether encrypted traffic 





was employed to communicate with the protected host. The 
following message was logged in the alert file at 


/var/log/snort directory: 





02/24-22:47:10.107040 ae] [1:1431:5] SSH attempt Perry 
[Classification: An attempted login using a suspicious username 


was detected] (Priority: 2] {TCP} 192.168.0.1:1884 -> 
192°. 168% 0.23322 





° LIDS: As a SSH is a service available by the 











protected server, LIDS is not involved. 





° Kernel Log File: A message to record the SSH 








connection was recorded in the kernel log file: 


Feb 24 21:23:01 LIDS sshd(pam_unix) [684]: session opened for user 





root by (uid=0) 


34 





This is misleading because we called the target 











machine LIDS. The log message above was recorded by the 





kernel and not by the HIDS called LIDS. 











e Log Monitor: Read the alert file, searching for 
an attempt to CONNECT record. After matching the SSH 
connection recorded by Snort, the log monitor was 


recorded in decoy.log file: 


LYING: hacker(192.168.0.1) CONNECT SSH DEST:192.168.0.3 at Sat 


Feb 21 15:16:33 2003. 





The log monitor also read the kernel message log file 











generated by the kernel log and generated the following 


record in decoy.log file: 





LYING: hacker (192.168.0.1) CONNECT SSH DEST:192.168.0.3 at Feb 21 
LS ELOs33: 2003's 


4. Other Suspicious Actions at Target Machine 


Using the PuTTY application, we logged on to the 





target machine and tried to execute some forbidden actions 
such as copying files, decompressing files, and killing 
processes (Figure 8). The rules for this are defined in 


Appendix B. 


3:5 








Figure 8. Process running at protected 
machine 


In Figure 8, we have some process running on the 














server as httpd (PID 1923) and sshd (PID 1929). The 


attacker will try to delete a file and copy a file from one 











directory to another; after that the intruder will try to 


kill some process. 


e Snort: Not involved. 
e LIDS: This blocked all of the attacks that the 


attacker tried to invoke against the target machine. 








The LIDS configuration needed to accomplish this and 
allow ssh and the HTTP Server to keep running are 


described in Appendix B. Following is the output of 








the message log file logged by LIDS when the attacker 
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tried to remove and copy a file (Figure 9) to the 


protected system. 


Feb 24 23:47:16 LIDS kernel: LIDS: rmdir (dev 3:2 inode 840392) 
pid 2031 ppid 1995 uid/gid (0/0) on (pts) : Attempt to rmdir 
apache_pb2.gif 


Feb 24 23:48:00 LIDS kernel: LIDS: cp (dev 3:2 inode 840382) pid 
2032 ppid 1995 uid/gid (0/0) on (pts) : Attempt to open 
index.html for writing, flag=32834 








After that, the attacker tried to kill the 





process httpd. Figure 9 shows the moment that the 


attacker attempted to check if there was a root 





privilege; the attacker ultimately realized that the 





commands, even with root privilege, would not work 


since the process was still running. 


cal/apache2/htdocs 


PRR RP RPP PREP PREP RePB 








Figure 9. Attacker deleting and copying 
files 


Next we show what happened when the attacker 





attempted to terminate process 1929 that was protected 


by the system (Figure 10). 
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Figure 10. Attacker trying to kill httpd 
process 


Here is the output of message log file. 


Feb 24 23:58:20 LIDS kernel: LIDS: bash (dev 3:2 inode 840369) 
pid 1995 ppid 1994 uid/gid (0/0) on (pts) : violated CAP_KILL 


Feb 24 23:58:38 LIDS kernel: LIDS: bash (dev 3:2 inode 840369) 
pid 1995 ppid 1994 uid/gid (0/0) on (pts) : violated 
CAP_KILL_PROTECTED - logging disabled for (60)s 


Feb 24 23:58:38 LIDS kernel: LIDS: bash (dev 3:2 inode 840369) 





pid 1995 ppid 1994 uid/gid (0/0) on (pts) : Attempt to kill 


pid=1929 with sig=15 








e Kernel Log File: Does not make any kind of 
record, as the commands are not executed. 


° Log Monitor: Read the alert fil generated by 











LIDS, searching for patterns that indicate a violation 








of rules, such as attempting to remove file (/rmdir/), 





to copy file (fep/) and Kail i process 

















(/CAP_KILL_VIOLATION/). After matching the patterns, 


the log monitor is recorded in decoy.log: 





LYING: hacker(192.168.0.1) ATTEMPT to RMDIR at Feb 24 23:48:00 
2003. 
LYING: hacker(192.168.0.1) ATTEMPT to COPY a FILE at Feb 24 


23:48:00 
LYING: hacker(192.168.0.1) ATTEMPT to KILL PROCESS 1929 at Feb 24 
23:58:38 2003. 
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V. DISCUSSION 


Military history suggests it is best to employ a 





layered, defense-in-depth strategy that includes 
protection, monitoring, and response [28]. Also, deception 
should be integrated with operations [29]. This is the 





strongest point of the architectur developed in the 


experimental design, which has its structure based on 





defense-in-depth. We showed that an intrusion-detection 


system can improve decoy capabilities if the two are 











integrated together . The detection system cannot be a job 
of only one machine or technology. Both of these 
capabilities have to be spread around th defensiv 
structure. 


As we do not have, at the present date, a defined 
decoy policy, we created one (Table 4) based on some 


xperience in the security and network field. With this 











simple and real example, we demonstrated simple detection 





and response capabilities. In our experiments, different 


phases of a simulated attack (PING, SCAN, CONNECTION and 








BAD ACTIONS), used different kinds of detection 








technologies that can be associated with different kinds of 


deception. 





In particular, with this architecture and 
implementation: a log monitor that reads and analyzes all 
detection alarms and then launches deception capabilities, 
we have a better coordination between an intrusion- 


detection system and a software decoy. This integration 





between defens modules and the log monitor is very 
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important since we can launch different decoys’ for 
different situations based on information about the whole 


arena. This significantly improves the performance of 





software decoy applications. 
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VI. CONCLUSIONS 





Some concepts of this work, such as defense-in-depth, 


centralized coordination, surveillance, event registry, and 





deception, have been widely used by military forces around 








the world for thousands of years. In the "information age" 





these tactics and strategies of military forces are 


migrating to the digital world. This makes sense becaus 














the digital world also encompasses; nemies, attacks, 








networks to be defended, defense planning to be performed, 
countermeasures to be executed, information warfare to be 


deployed, technology to b developed, and deceptions to 








fool the enemy. 


Our experiments in this thesis demonstrated the 
advantages of intrusion-detection software as a component 
in defense of computer systems, much as any military 


defense plan should be based on battlefield intelligence 





information. But intrusion information can be voluminous 





and needs to be collected and fused by a central "brain" as 





we described in this research. In the proposed 


architecture, network intrusion detection, host intrusion 





detection and log files acted as our defense modules. 


Their integration with a log monitor became vital for the 





implementation of decoy capabilities. 


This approach is not new and was first proposed in 


1980 [30]. Since then a log analysis has been one of the 





most overlooked aspects of operational computer security. 





Many organizations spend hundreds of thousands of dollars 











on intrusion-detection systems (IDS) deployments, but still 
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ignore their firewall logs. Bird [31] suggests that the 








next wave in security will be to usefully correlate and 
process the contents of multiple logs and intrusion- 


detection technology in real time. 


A. POSSIBLE FUTURE WORK 


More tests and experiments are necessary to best 


address some issues not covered in this research: 


e Synchronization of all modules with timestamps would 





be useful as the timing of events is a very 


important issue in this kind of approach. 





e Encrypted communication between defense modules and 





the coordination module could help conceal 


deceptions. 


e Redundancy of all data stored in the coordination 


module could increase robustness. 





e Defense modules could be created with a high level 
of specialization. The rules and policy could be 
customized for each environment and each defense 


module. 





e Integration of the intrusion-detection system with 





























other defens technology using the Intruder 
Detection and Isolation Protocol (IDIP) could 
provide additional resources to facilitate 
implementation. 
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VII. APPENDIXES 


APPENDIX A -—- LOG MONITOR PROGRAM 


#!/usr/bin/perl 


HH HH HH EH HH HE EH EE OE EE EEE HE ## 
# Load Configuration 
HHH HE HH EH HE EE EH EE OEE EE HH OE ## 
Sdecoy_file = "./decoy.log"; 
Sping_file = "/var/log/snort/alert"; 

Sscan_file = "/var/log/snort/alert"; 

Sconnect_file = "/var/log/snort/alert"; 
Slogin_root_file = "/var/log/messagens"; 














He GH Ee EE HH EH EE EH EEE HR EH EE HE EE HE EH EE EE OE EE ERE EE EE HE EE HP EH EEE EO EE EE EE HEE EE HE 
open(PING, $ping_file) or die "can't open PING file: S$ping_file: $!\n"; 
print "Checking $ping_file ...\n"; 
while(<PING>) { 
next unless /ICMP Packet | Portscan detected | TELNET attempt /; 
if ("S&" == "ICMP Packet") { 
my $status = "PING"; 
if (/.* (\dt\.\dt\.\dt\.\dt) -> (\dt\.\dt\.\dt\.\dt)/) { 
&check_IP_Table($1, $2, Sstatus); 








}#end if 
}#tend if 
if ("S&" == "Portscan detected") { 
my $status = "SCAN"; 
if (/.* (\dt\.\d+\.\dt\.\d+) :\dt+ -> (\d+\.\dt\.\d+\.\dt+):\d+/) { 
&check_IP_Table($1, $2, Sstatus); 
} 
}#tend if 
if ("S&" == "TELNET attempt") { 
my $status = "CONNECT"; 
if (/.* (\dt\.\dt\.\dt\.\d+) :\dt -> (\dt\.\d+\.\d+\.\d+t)/) { 
&check_IP_Table($1, $2, Sstatus); 
}#end 
}#tend if 
}#end while 


HHPEERRRGE EE EEG GREE HEHEHE HG EE HEHE GG EE HE EE EE EE RE EHH EEE EGE HH HE EE EE HH HH HF 
open (LOG, "/var/log/messages") or die "Can't open /var/log/messagens\n"; 
print "\nChecking $login_root_file..\n"; 
while (<LOG>) { 

next unless /session opened/; 

my S$status = "LOGIN"; 

#$total_good_sutt; 

if (/session opened for user (\w) by/) { 

&check_IP_Table($1, undef, S$status); 

}#tend if 

}#end while 





FERRER REE EE EEG GRRE EH HEE EGG EE EEE GG GEE HH EE EEE EEE EE EEE EG GE HH EHH EE EE HH HH HF 
#Area for Sub Rotines 
HERRERA EE EEG GRRE EH HEHE EGE EH EEE GEE HH EEE EE EEE EH HE EEE EG GE HH EEE EE EE HH HH HE 








sub write_decoy_file { 
my $message = $_[0]; 
print STDOUT $message; 
open (DECOY, ">>Sdecoy_file"); 
print DECOY $message; 
close (DECOY); 
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}# end of write_decoy_file 


sub check_IP_Table { 
my (Ssource, Sdest, $status) 
Skey_hash "Ssource.$status"; 
ae 


(Shash{$key_hash}) { 
Shash{Skey_hash}++; 
"\tIP Ssource has Shash{$key_hash} 


print 
end if 
lse { 
print "\tNew Hacker Activity: 
end elsif 
check_IP_Table 








}#end 


sub check_hacker { 
my (S$source, $dest, S$status) 
my Sdate localtime(); 
(Sstatus eq "PING") { 
é&write_decoy_file("\t\tHONESTY: 
&wri 


@_; 


# 


aot 


#end if 

if (S$status eq "S 

&write_decoy_f 
&wri 
&wri 


CAN") { 
ile ("\t\tLYING: 


e("\ 


te_decoy_fil 





end if 
(Sstatus eq "C 
é&write_decoy_f 
&wri 





ONNECT") { 

ile ("\t\tLy 

te_decoy_fil 

#end if 

if (S$status eq "L 

&write_decoy_f 
&wri 


OGIN") { 
ile ("\t\tLy 
te_decoy_fil 














fend if 
}#end check_hacker 


IP number: 
&check_hacker ($source, 


te_decoy_file ("hacker (Ssource) 


t\tRedirecting to FAKE SE 


wee 


hacker (S$source) 


MS) 9 


hacker (S$source) 


attempts\n"; 


Ssource,S$status\n"; 


Sdest, S$status); 


aD 
Sstatus DEST:$dest\n"); 


")7 


te_decoy_file ("hacker (Ssource) 


Sstatus DESt:$dest\n"); 
RVER...\n"); 


Sstatus DEST:S$dest\n"); 





Sstatus DEST:S$dest\n"); 
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APPENDIX B - LIDS AND INSTALLATION 


This appendix provides guidelines to implement LIDS in 











the LINUX system. This guide is based on the documentation 











available in the LIDS official home page [42], along with 


some of our own updates. 











Before installing LIDS in the machine, you must 


download the "pure" kernel developed by Linux (or did you 














mean Linus Torvalds?); LIDS is a patch of the kernel. Many 


distributors, including Red Hat, customize their kernel. 











Although this is not a problem, LIDS only runs over Linux 





pure kernel. There are many documents and books about 


Linux Kernel compilation [41]. 


1. System Environment 


LINUX RedHat 8 


LIDS version 
etc/lids 


Configuration Files 
Lids.cap 
3 
ee 


























2. Installation 











Before installing LIDS, the kernel must be patched. 








To do this, download the LIDS patch [42] that matches the 


specific kernel, which for this research, was lids-1.1.1r2- 





2.4.18. After that follow the steps: 


01 cd /usr/src/linux This is the directory that you unpacked the original 
Linux kernel. 





patch -pl < | Patch the Linux kernel 
/usr/src/lids-1.1.1r2- 





SCE EET a 
Reconpile the Linux kernel 


make xconfig Open Linux kernel menu. Make sure that the following 
options are enabled: 
* Prompt for development and/or incomplete 
code/drives 
Sysctl support 
the LIDS option in the kernel, make sure that the 
Llowing options are enabled: 
Linux Intrusion-detection System support 
Attempt not to flood logs 
Allow switching LIDS protection 
Allow reloading config. File 
Port scanner detector in kernel 
Send security alerts through network 
| make dep clean bzImage | 


Pc al 
make dep clean bzImage Complet 
| 09 | 
i == 














cd /usr/src/lids-— | Go to lids directory and install lidsadm an lidsconf 
bid. le2-2.4.-18 with ./configure && make && make install 
p 


é /usr/src/lids— | This will create the files in order to reboot the 
1.1,14r2- machine. To the system work properly we have to 


2.4.18/example/lids.* change this file according to our system 
/etc/lids configuration and security police 


Generate the password file lids.pwd 
Reboot the machine 


There are some important commands to deal with LIDS implementation and debug: 








lidsadm -S a= — | Disable LIDS completely 
Enable LIDS completely 
+LIDS_GLOBAL 


12 In the official referenc ther old commands that use lidsadm 
instead of lidsconf. Use the both commands lidsadm -help and lidsconf -help 


to make sure about the right command. 














3). LIDS Files Configurations 


e Lids.cap file: 

0: In a system with the _POSIX_CHOWN_RESTRICTED option defined, this overrides the 
estriction 

0: of changing file ownership and group ownership. 


: CAP_CHOWN 
1: Override all DAC access, including ACL execute access if _POSIX_ACL is defined. 


xcluding 
1: DAC access covered by CAP_LINUX_IMMUTABLE. 








: CAP_DAC_OVERRIDE 


2: Overrides all DAC restrictions regarding read and search on files and directories, 
including 

2: ACL restrictions if _POSIX_ACL is defined. Excluding DAC access covered by 
2: CAP_LINUX_IMMUTABLE. 








: CAP_DAC_READ_SEARCH 

















3: Overrides all restrictions about allowed operations on files, where file owner ID 





must be equal 

### 3: to the user ID, except where CAP_FSETID is applicable. It doesn't override MAC and 
DAC 
# 3: restrictions. 
# 


ae 
Ww 


>: CAP_FOWNER 


4: Overrides the following restrictions that the effective user ID shall match the 
le owner ID 
4: when setting the S_ISUID and S_ISGID bits on that file; that the effective group 
(or one of 
4: the supplementary group IDs) shall match the file owner ID when setting the 
SGID bit on 
4: that file; that the S_ISUID and S_ISGID bits are cleared on successful return from 
own (2) 
4: (not implemented). 


B- 


ie) 


Da | 
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aS 


:CAP_FSETID 


5: Overrides the restriction that the real or effective user ID of a process sending 
signal must 
5: match the real or effective user ID of the process receiving the signal. 


























| aR SE @ Se 


ol 


:CAP_KILL 


setgid(2) manipulation 
setgroups (2) 
forged gids on socket credentials passing. 














+ FE dR FR SE 


oO 


set*uid(2) manipulation (including fsuid). 
forged pids on socket credentials passing. 





Al] 
Al 





# 
# 
# 
+ 


~] 


:CAP_SETUI 


Transfer any capability in your permitted set to any pid, remove any capability in 


ie} 
Sc 
K 


8: permitted set from any pid. 


+ 4b EK Sk 


foe) 


: CAP_SETPCAP 

9: Allow modification of S_IMMUTABLE and S_APPEND file attributes. 
: CAP_LINUX_IMMUTABLE 

Allows binding to TCP/UDP sockets below 1024. 


0:CAP_NET_BIND_SERVICE 





Allow broadcasting, listen to multicast. 


+ 4h oe 


: CAP_NET_BROADCAST 


llow interface configuration 

administration of IP firewall, masquerading and accounting 
setting debug option on sockets 

modification of routing tables 

setting arbitrary process / process group ownership on sockets 
binding to any address for transparent proxying 

setting TOS (type of service) 

setting promiscuous mode 

clearing driver statistics 

multicasting 

read/write of device-specific registers 

















VNNNNNNNNNN 
DDD DD 


Se Se SE OSE OSE OSE OSE OHH HEHE 


_ADMIN 


























llow_ use of RAW sockets 





13: - Allow use of PACKET sockets 
3:CAP_NET_RAW 


14: - Allow locking of shared memory segments 
14: -— Allow mlock and mlockall (which doesn't really have anything to do with IPC) 


P_IPC_LOCK 
Override IPC ownership checks. 


P_IPC_OWNER 





Insert and remove kernel modules. 





P_SYS_MODULE 


- Allow ioperm/iopl and /dev/port access 
- Allow /dev/mem and /dev/kmem acess 
- Allow raw block devices (/dev/[sh]d??) acess 





P_SYS_RAWIO 
Allow use of chroot () 


P_SYS_CHROOT 








Allow ptrace() of any process 


P_SYS_PTRACE 








Allow configuration of process accounting 





BP JS25 2PACCE 


configuration of the secure attention key 
administration of the random device 

device administration (mknod) 

examination and configuration of disk quotas 
configuring the kernel's syslog (printk behaviour) 
setting the domainname 

setting the hostname 

calling bdflush() 

mount() and umount(), setting up new smb connection 
some autofs root ioctls 

nfsservectl 
VM86_REQUEST_IRQ 

to read/write pci config on alpha 

irix_prctl on mips (setstacksize) 

flushing all cache on m68k (sys_cacheflush) 

llow removing semaphores 

ed instead of CAP_CHOWN to "chown" IPC message queues, semaphores and shared 


Coho Db he 





locking/unlocking of shared memory segment 
turning swap on/off 
forged pids on socket credentials passing 
setting readahead and flushing buffers on block devices 
setting geometry in floppy driver 
turning DMA on/off in xd driver 
administration of md devices (mostly the above, but some extra ioctls) 
tuning the ide driver 
access to the nvram device 
administration of apm_bios, serial and bttv (TV) device 
manufacturer commands in isdn CAPI support driver 
reading non-standardized portions of pci configuration space 
DDI debug ioctl on sbpcd driver 

ports 



































SH SR EOE OSE SEO SE SESE SECS SESE ESSE EC SEE SEE SEE SEE SEE EE HEHEHE 








Po DD 





# 
# 
a 
# 
# 


# 
# 


# 
# 
s 
# 
# 
+ 


2 

















got 


22:3 


21: - Allow sending raw qic-117 commands 
21: - Allow enabling/disabling tagged queuing on SCSI controllers and sending 


rbitrary SCSI commands 


21: - Allow setting encryption key on loopback filesystem 


:CAP_SYS_ADMIN 


22: Allow use of reboot () 
CAP_SYS_BOOT 


23: - Allow raising priority and setting priority on other (different UID) processes 
23: - Allow use of FIFO and round-robin (realtime) scheduling on own processes and 


etting 


Za the scheduling algorithm used by another process. 


CAP_SYS_NICE 


Override resource limits. Set resource limits. 


|oSR AE FE se + OSE 4 FE SE OE HE OO FE FE SE 
iN) 
dS 


+ 46 4h Se 




















NO 
ol 


NO 
oO 




















verri 


24: -— Override quota limits. 
24: - Override reserved space on ext2 filesystem 
24: NOTE: ext2 honors fsuid when checking for resource overrides, so you can 


24: using fsuid too 

24: Override size restrictions on IPC message queues 

24: Allow more than 64hz interrupts from the real-time clock 
24: Override max number of consoles on console allocation 
24: Override max number of keymaps 





:CAP_SYS_RESOURCE 


25: - Allow manipulation of system clock 
25: - Allow irix_stime on mips 
25: - Allow setting the real-time clock 


:CAP_SYS_TIME 


26: - Allow configuration of tty devices 
26: - Allow vhangup() of tty 





{CAP SYS TTY CONFIG 


27: Allow the privileged aspects of mknod() 


: CAP_MKNOD 


28:Allow taking of leases on files */ 





: CAP_LEASE 


Restricts viewable processes by a user. 
_HIDDEN 
Allow to kill protected processes 


KILL_PROTECTED 





Protect process against signals 











_PROTECTED 


This file is auto generated by lidsconf 
Please do not modify this file by hand 





Sil 


:791855:770:/sbin:0-0 
:840334:770:/bin:0-0 
:2:769:/boot:0-0 
2921136:770:/lib: 
2323201:770:/usr: 
2:226241:770:/etce: 
>745099:770:/etc/lids:0-0 
:743370:770:/var/log:0-0 
>745391:770:/var/log/wtmp: 0-0 
:/bin/login:7:0:743373:770:/var/log/lastlog:0-0 
:/etc/re.d/re:16:-1:-1:30:CAP_KILL_PROTECTED: 0-0 
:/etc/re.d/rce:16:-1:-1:12:CAP_NET_ADMIN: 0-0 
:/etc/re.d/rce:16:-1:-1:21:CAP_SYS_ADMIN:0-0 
:/etc/re.d/init.d/halt:16:-1:-1:30:CAP_KILL_PROTECTED: 0-0 
:/etc/rce.d/init.d/halt:16:-1:-1:21:CAP_SYS_ADMIN:0-0 
:/etc/re.d/init.d/halt:16:-1:-1:17:CAP_SYS_RAWIO:0-0 
:/etc/rce.d/init.d/halt:16:-1:-1:12:CAP_NET_ADMIN:0-0 
:0:290881:770:/root:0-0 
:770:/usr/sbin/sshd:16:0:22-22:10:CAP_NET_BIND_SERVICE: 0-0 
:770:/usr/sbin/sshd:16:0:-1:31:CAP_PROTECTED: 0-0 
:770:/usr/X11R6/bin/XF86_SVGA:16:0:-1:17:CAP_SYS_RAWIO:0-0 
:770:/usr/bin/ssh:16:0:0-1024:10:CAP_NET_BIND_SERVICE: 0-0 
:791855:770:/sbin:0-0 
:840338:770:/usr/local:0-0 
>743375:770:/opt:0-0 
:921138:770:/usr/local/etc:0-0 
:227208:770:/etc/shadow: 0-0 
:0:227644:770:/etc/lilo.conf:0-0 
:770:/bin/login:1:0:227208:770:/etc/shadow: 0-0 
:770:/bin/su:1:0:227208:770:/etc/shadow: 0-0 
:770:/bin/su:16:0:-1:7:CAP_SETUID:0-0 
:770:/bin/su:16:0:-1:6:CAP_SETGID:0-0 
:770:/bin/bash:7:0:293155:770:/root/.bash_history:0-0 
:770:/bin/login:7:0:745391:770:/var/log/wtmp: 0-0 
:770:/sbin/init:7:0:745391:770:/var/log/wtmp: 0-0 
:770:/sbin/init:7:0:743373:770:/var/log/lastlog:0-0 
0 
0 


OOOO COC0O0O OC * 


© 
S 
OT: 


D.O-O 1S O'O10 16 
AYNWORRPRPREER 


fee) 
aS 
(=) 

N 











:770:/sbin/halt:7:0:743373:770:/var/log/lastlog: 0-0 
:770:/sbin/halt:7:0:745391:770:/var/log/wtmp: 0-0 
:770:/etc/re.d/re.sysinit:7:1:745391:770:/var/log/wtmp: 0-0 
:770:/etc/re.d/re.sysinit:7:1:743373:770:/var/log/lastlog:0-0 
:770:/sbin/hwcelock:7:0:226410:770:/etc/adjtime: 0-0 
:770:/sbin/init:16:0:-1:5:CAP_KILL: 0-0 
:770:/etc/re.d/init.d/halt:16:1:-1:5:CAP_KILL: 0-0 
:770:/sbin/update:16:0:-1:21:CAP_SYS_ADMIN:0-0 
:0:599268:770:/var/www: 0-0 
:339533:770:/usr/bin/consolehelper: 0-0 
20:226493:770:/etc/ssh/sshd_config:0-0 
20::0:0:227197:770:/etc/ssh/ssh_host_key:0-0 
0:0::0:0:227214:770:/etc/ssh/ssh_host_dsa_key:0-0 
387985:770:/usr/sbin/sshd:1:0:226493:770:/etc/ssh/sshd_config:0-0 
387985:770:/usr/sbin/sshd:1:0:227197:770:/etc/ssh/ssh_host_key:0-0 
387985:770:/usr/sbin/sshd: 








0 
S$ 
S30 te 

0 


O.8 

:0:227214:770:/etc/ssh/ssh_host_dsa_key:0-0 
387985:770:/usr/sbin/sshd:7:0:745391:770:/var/log/wtmp: 0-0 
387985:770:/usr/sbin/sshd:7:0:743373:770:/var/log/lastlog:0-0 
387985:770:/usr/sbin/sshd: :0:-1:7:CAP_SETUID:0-0 
387985:770:/usr/sbin/sshd: :0:-1:6:CAP_SETGID:0-0 
387985:770:/usr/sbin/sshd: :0:-1:3:CAP_FOWNER: 0-0 
387985:770:/usr/sbin/sshd: :0:-1:0:CAP_CHOWN: 0-0 
387985:770:/usr/sbin/sshd: :0:-1:1:CAP_DAC_OVERRIDE: 0-0 
387985:770:/usr/sbin/sshd:16:0:22-22:10:CAP_NET_BIND_SERVICE: 0-0 
387985:770:/usr/sbin/sshd: :0:-1:18:CAP_SYS_CHROOT: 0-0 
387985:770:/usr/sbin/sshd:1:0:227208:770:/etc/shadow: 0-0 
857457:770:/usr/local/bin/snort:16:0:-1:1:CAP_DAC_OVERRIDE: 0-0 
857457:770:/usr/local/bin/snort:16:0:-1:13:CAP_NET_RAW: 0-0 
857457:770:/usr/local/bin/snort:16:0:-1:29:CAP_HIDDEN: 0-0 
857457:770:/usr/local/bin/snort:16:0:-1:7:CAP_SETUID: 0-0 
857457:770:/usr/local/bin/snort:16:0:-1:6:CAP_SETGID:0-0 
857457:770:/usr/local/bin/snort:7:0:81730:770:/var/log/snort:0-0 


4h 
7 




















e Lids.net file configuration 
LIDS 


Send Alert Message From Network 
for lids 0.9.8 
xie@gnuchina.org 


MAIL_SWITCH = 0 
, send alert function is on 
0, send alert function is off 


L_SWITCH= 0 


# MAIL _RELAY=hex IP:port 
# IP11.1 of the machine that will be directly connected by LIDS 
# 


for relaying its mails. Port is usually 25, but who knows... 
MAIL_RELAY=127.0.0.1:25 





MATIL_SOURCE=source machine 
Name of the source machine, used for the ehlo identification. 


Note that a bad name here could make the mail relay refuse your 
mails. 


L_ SOURCE=decoy.cs.nps.navy.mil 


IL_FROM=sender address 
Sender address, which will also be in the **from'' field. 
__FROM= LIDS_ALERT@nps.navy.mil 


IL_TO=recipient address 
Recipient address. 
TO= vjmontei@nps.navy.mil 








IL_SUBJECT= subject 
Subject of the mail. 
L SUBJECT= LIDS ALert 

















° Lids.pw password file 
8fee5733a4caef5b1992e25508e0428740f99be7 
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APPENDIX C —- SNORT FILE CONFIGURATION 


# Modified by Valter Monteiro - Thesis Research 


# egy pt a asec tet Bae ip tetera el tren se Selah pA oss caps ween eh pes Pac js Soar Boag Na ibe be So we a pan a ae wy 
# http://www.snort.org Snort 1.9.0 Ruleset 

# Contact: snort-sigs@lists.sourceforge.net 

# a a Se Ce ee a eg a ge Pa re ey ee ee 
# NOTE:This ruleset only works for 1.9.0 and later 
# Sc ape Nana Nh md oP a a ge Tg SS Te es das Peek: SOR A i nh ak See ag gs es in ag a pa tig 


# SId: snort.conf,v 1.110 2002/08/14 03:17:58 chrisgreen Exp $ 


HHREERRRRE EE EEE GRRE SHEER aaa EE EEE EGE EH EEE EEE 
# This file contains a sample snort configuration. 
# You can take the following steps to create your 

# own custom configuration: 


Set the network variables for your network 
Configure preprocessors 
Configure output plugins 
Customize your rule set 


HGH HEHE HH HE HE EE HH EH EE EEE EE EEE EH EE ER EH EE EE EE HR EE HF 
Step #1: Set the network variables: 


You must change the following variables to reflect 
your local network. The variable is currently 
setup for an RFC 1918 address space. 

You can specify it explicitly as: 

var HOME_NET 192.160.0.0/24 

or use global variable $<interfacename>_ADDRESS 
which will be always initialized to IP address and 
netmask of the network interface which you run 
snort at. 


var HOME_NET Seth0O_ADDRESS 


You can specify lists of IP addresses for HOME_NET 
by separating the IPs with commas like this: 


var HOME_NET [10.1.1.0/24,192.168.1.0/24] 
MAKE SURE YOU DON'T PLACE ANY SPACES IN YOUR LIST! 


or you can specify the variable to be any IP address 
like this: 


Se Se SE OSE OSE OSH OSE OE SE SE SESE SHE SE SHE SHE SE SHE SE SESE SE SHE SESE SHE SE HE SE SHE HE SE HE 


var HOME_NET 192.168.0.3/24 


# Set up the external network addresses as well. 
# A good start may be "any" 


var EXTERNAL_NET any 


Configure your server lists. This allows snort to only look for attacks 

to systems that have a service up. Why look for HTTP attacks if you are 

not running a web server? This allows quick filtering based on IP addresses 
These configurations MUST follow the same configuration scheme as defined 
above for $HOME_NET. 


Se Se OSE EOE 


# List of DNS servers on your network 
var DNS_SERVERS $HOME_NET 
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# List of SMTP servers on your network 
var SMTP_SERVERS $HOME_NET 


# List of web servers on your network 
var HTTP_SERVERS SHOME_NET 


# List of sql servers on your network 
var SQL_SERVERS $HOME_NET 











# List of telnet servers on your network 

var TELNET_SERVERS $HOME_NET 

# Configure your service ports. This allows snort to look for attacks 
# destined to a specific application only on the ports that application 
# runs on. For example, if you run a web server on port 8081, set your 
# HTTP_PORTS variable like this: 

# 

# var HITP_PORTS 8081 

# 

# Port lists must either be continuous [eg 80:8080], or a single port [eg 80]. 
# We will adding support for a real list of ports in the future. 


# Ports you run web servers on 
var HTTP_PORTS 80 


# Ports you want to look for SHELLCODE on. 
var SHELLCODE_PORTS !80 


# Ports you do oracle attacks on 
var ORACLE_PORTS 1521 











other variables 


modifying the signatures when they do, we add them to this list of 
servers. 
var AIM_SERVERS 
[64.12.24.0/24, 64.12.25.0/24, 64.12.26.14/24, 64.12.28.0/24, 64.12.29.0/24, 64.12.161.0/24, 64.12.163.0/24,205 


# 
# 
# AIM servers. AOL has a habit of adding new AIM servers, so instead of 
# 
# 


# Path to your rules files (this can be a relative path) 
var RULE_PATH ../rules 


HE aE EEE ae aE EEE EE EE EE EEE EE EE EE EEE EEE EE EE EE HE 








# Step #2: Configure preprocessors 

# 

# General configuration for preprocessors is of 

# the form 

# preprocessor <name_of_processor>: <configuration_options> 

# frag2: IP defragmentation support 

# ee ee ee ey ee 

# This preprocessor performs IP defragmentation. This plugin will also detect 
# people launching fragmentation attacks (usually DoS) against hosts. No 

# arguments loads the default configuration of the preprocessor, which is a 
# 60 second timeout and a 4MB fragment buffer. 

# The following (comma delimited) options are available for frag2 

# timeout [seconds] - sets the number of [seconds] than an unfinished 

# fragment will be kept around waiting for completion, 
# if this time expires the fragment will be flushed 
# memcap [bytes] - limit frag2 memory usage to [number] bytes 

# (default: 4194304) 

# 

# min_ttl [number] - minimum ttl to accept 

# 

# ttl_limit [number] - difference of ttl to accept without alerting 

# will cause false positves with router flap 

# 
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# Frag2 uses Generator ID 113 and uses the following SIDS 

# for that GID: 

# SID Event description 

# Fe een ae fee SO, Se ny ee 

# 1 Oversized fragment (reassembled frag > 64k bytes) 
# 2 Teardrop-type attack 


preprocessor frag2 
# stream4: stateful inspection/stream reassembly for Snort 


Use in concert with the -z [alll|lest] command line switch to defeat 
stick/snot against TCP rules. Also performs full TCP stream 
reassembly, stateful inspection of TCP streams, etc. Can statefully 
detect various portscan types, fingerprinting, ECN, etc. 


stateful inspection directive 
no arguments loads the defaults (timeout 30, memcap 8388608) 
options (options are comma delimited): 
detect_scans - stream4 will detect stealth portscans and generate alerts 
when it sees them when this option is set 
detect_state_problems - detect TCP state problems, this tends to be very 
noisy because there are a lot of crappy ip stack 
implementations out there 


disable_evasion_alerts - turn off the possibly noisy mitigation of 
overlapping sequences. 


min_ttl [number] —- set a minium ttl that snort will accept to 
stream reassembly 


ttl_limit [number] - differential of the initial ttl on a session versus 
the normal that someone may be playing games. 
Routing flap may cause lots of false positives. 





keepstats [machine|binary] - keep session statistics, add "machine" to 
get them in a flat format for machine reading, add 
"binary" to get them in a unified binary output 
format 

noinspect - turn off stateful inspection only 

timeout [number] - set the session timeout counter to [number] seconds, 

default is 30 seconds 

memcap [number] - limit stream4 memory usage to [number] bytes 

log_flushed_streams - if an event is detected on a stream this option will 
cause all packets that are stored in the stream4 





packet buffers to be flushed to disk. This only 
works when logging in pcap mode! 


Stream4 uses Generator ID 111 and uses the following SIDS 
for that GID: 
SID Event description 
Stealth activity 
Evasive RST packet 
Evasive TCP packet retransmission 
TCP Window violation 
Data on SYN packet 
Stealth scan: full XMAS 
Stealth scan: SYN-ACK-PSH-URG 
Stealth scan: FIN scan 
Stealth scan: NULL scan 
Stealth scan: NMAP XMAS scan 
Stealth scan: Vecna scan 
Stealth scan: NMAP fingerprint scan stateful detect 
Stealth scan: SYN-FIN scan 
TCP forward overlap 


AINA BWNHE 
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reprocessor stream4: detect_scans, disable evasion alerts 
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# tcp stream reassembly directive 
# no arguments loads the default configuration 
# Only reassemble the client, 


will turn on reassembly for all ports, "default" will turn 
on reassembly for ports 21, 23, 25), 53;- 80, 143, 110, 111 
and 513 


# Only reassemble the default list of ports (See below), 

# Give alerts for "bad" streams 

# 

# Available options (comma delimited): 

# clientonly - reassemble traffic for the client side of a connection only 
# serveronly - reassemble traffic for the server side of a connection only 
# both - reassemble both sides of a session 

# noalerts - turn off alerts from the stream reassembly stage of stream4 

# ports [list] - use the space separated list of ports in [list], "all" 

# 

# 

# 


preprocessor stream4_reassemble 


http_decode: normalize HTTP requests 

http_decode normalizes HTTP requests from remote 

machines by converting any %XX character 

substitutions to their ASCII equivalent. This is 

very useful for doing things like defeating hostile 

attackers trying to stealth themselves from IDSs by 

mixing these substitutions in with the request. 

Specify the port numbers you want it to analyze as arguments. 


Major code cleanups thanks to rfp 


unicode —- normalize unicode 

iis_alt_unicode - %u encoding from iis 

double_encode - alert on possible double encodings 
iis_flip_slash - normalize \ as / 

full_whitespace - treat \t as whitespace ( for apache ) 


for that GID: 


Se Se SE OSE OSE OSHS SHE SHE SE SHE SE SE SHE SE HE SESE HE SFE HEHE SE 


SID Event description 
1 UNICODE attack 
2 NULL byte attack 


preprocessor http_decode: 80 unicode iis_alt_unicode double_encode iis_flip_slash full_whitespac 


rpc_decode: normalize RPC traffic 

RPC may be sent in alternate encodings besides the usual 
4-byte encoding that is used by default. This preprocessor 
normalized RPC traffic in much the same way as the http_decode 
preprocessor. This plugin takes the ports numbers that RPC 
services are running on as arguments. 

The RPC decode preprocessor uses generator ID 106 and does not 
generate any SIDs at this time. 


Se Se SE OSE OSE OH OEE HE 


preprocessor rpc_decode: 111 32771 


Detects Back Orifice traffic on the network. This preprocessor 
uses the Back Orifice "encryption" algorithm to search for 

traffic conforming to the Back Orifice protocol (not BO2K). 

This preprocessor can take two arguments. The first is "-nobrute" 
which turns off the plugin's brute forcing routine (brute forces 
the key space of the protocol to find BO traffic). The second 
argument that can be passed to the routine is a number to use 

as the default key when trying to decrypt the traffic. The 
default value is 31337 (just like BO). Be aware that turning on 
the brute forcing option runs the risk of impacting the overall 
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performance of Snort, you've been warned... 


The Back Orifice detector uses Generator ID 105 and uses the 
following SIDS for that GID: 
SID Event description 


Se SH ORE SHE SHE HE 


Back Orifice traffic detected 
preprocessor bo: -nobrute 


telnet_decode: Telnet negotiation string normalizer 

This preprocessor "normalizes" telnet negotiation strings from 

telnet and ftp traffic. It works in much the same way as the 
http_decode preprocessor, searching for traffic that breaks up 

the normal data stream of a protocol and replacing it with 

a normalized representation of that traffic so that the "content" 
pattern matching keyword can work without requiring modifications. 

This preprocessor requires no arguments. 

Portscan uses Generator ID 109 and does not generate any SID currently. 





Se SE Se OSE OSE SHE SHE SHE HE 


preprocessor telnet_decode 





# Portscan: detect a variety of portscans 

# a a Re 

# portscan preprocessor by Patrick Mullen <p_mullen@linuxre.net> 

# This preprocessor detects UDP packets or TCP SYN packets going to 

# four different ports in less than three seconds. "Stealth" TCP 

# packets are always detected, regardless of these settings. 

# Portscan uses Generator ID 100 and uses the following SIDS for that GID: 
# SID Event description 

# ieee: 8 are Sas ee pe ee 

# 1 Portscan detect 

# 2 Inter-scan info 

# 3 Portscan End 

# preprocessor portscan: SHOME_NET 4 3 portscan.log 

# Use portscan-ignorehosts to ignore TCP SYN and UDP "scans" from 

# specific networks or hosts to reduce false alerts. It is typical 

# to see many false alerts from DNS servers so you may want to 

# add your DNS servers here. You can all multiple hosts/networks 

# in a whitespace-delimited list. 

# 

#preprocessor portscan-ignorehosts: 0.0.0.0 

# arpspoof 

# a oe a ey EN ee a eS a a Ee ny age ey Sa Pe See te RE en Pea 

# Experimental ARP detection code from Jeff Nathan, detects ARP attacks, 
# unicast ARP requests, and specific ARP mapping monitoring. To make use 


# of this preprocessor you must specify the IP and hardware address of hosts on # the same layer 2 segme 
IP MAC combo per line. 


# Also takes a "-unicast" option to turn on unicast ARP request detection. 
# Arpspoof uses Generator ID 112 and uses the following SIDS for that GID: 
# SID Event description 

# Sh te Se ey ag ee ee ry 

# 1 Unicast ARP request 

# 2 Etherframe ARP mismatch (src) 

# 3 Etherframe ARP mismatch (dst) 

# 4 ARP cache overwrite attack 


#preprocessor arpspoof 
#preprocessor arpspoof_detect_host: 192.168.40.1 f£0:0£:00:f0:0f:00 


# ASN1 Decode 


# Sake Fas Je fame Se fas ia Sanh sl gy fet tet ode to oe Sale ei eh aen bee Sc oe 
# This is an experimental preprocessor. ASN.1 decoder and analysis plugin 
# from Andrew R. Baker. This preprocessor will detect abuses of the ASN.1 





# protocol that higher level protocols (like SSL, SNMP, x.509, etc) rely on. 
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# The ASN.1 decoder uses Generator ID 115 and uses the following SIDs for 
# that GID: 
SID Event description 

1 Indefinite length 

2 Invalid length 

3 Oversized item 

4 ASN.1 specification violation 

5 Dataum bad length 


Se Se SE OH HE SHE HE 


preprocessor asnl_decode 


This is an experimental preprocessor. Polymorphic shellcode analyzer and 
detector by Dragos Ruiu. This preprocessor will watch traffic for 
polymorphic NOP-type sleds to defeat tools like ADMutate. The Fnord detector 
uses Generator ID 114 and the following SIDs: 

SID Event description 


1, NOP-sled detected 


Se SE OSE HEHE SE HE SHE 


se 


preprocessor fnord 


Conversation 


This preprocessor tracks conversations for tcp, udp and icmp traffic. Tt 
is a prerequisite for running portscan2. 


allowed_ip_protcols 1 6 17 
list of allowed ip protcols ( defaults to any ) 


timeout [num] 


conversation timeout ( defaults to 60 ) 


max_conversations [num] 
number of conversations to support at once (defaults to 65335) 


alert_odd_protocols 
alert on protocols not listed in allowed_ip_protocols 


Se Se SE OSE OSE OSE OSE OSHE SHE SHE HE SE SHE SHE SHE SHE SEH 


preprocessor conversation: allowed_ip_protocols all, timeout 60, max_conversations 32000 


# Portscan2 


# 
# 
# Available options: 

# scanners_max [num] 
# targets_max [num] 
# target_limit [num] 
# port_limit [num] 

# timeout [num] 

# log [logdir] 


preprocessor portscan2: scanners_max 3200, targets_max 5000, target_limit 5, port_limit 20, 


# Experimental Perf stats 

# aaispado mt cae adit te se aa ae ase ae ke eae en eee eco Sw 

# No docs. Highly subject to change. 

# 

# preprocessor perfmonitor: console flow events time 10 


HHREERRRGE EE EEE GRRE HEE EG GE EH EGG GE EH HE EE EH HEE HH EEE EEE HH EE 
# Step #3: Configure output plugins 

# 

# Uncomment and configure the output plugins you decide to _ use. 


time 


General configuration for output plugins is of the form: 
output <name_of_plugin>: <configuration_options> 


alert_syslog: log alerts to syslog 


Se Se OSE SE OE OSE 


Use one or more syslog facilities as arguments 


Se Se SE 


output alert_syslog: LOG_AUTH LOG_ALERT 


log_tcpdump: log packets in binary tcpdump format 


The only argument is the output file name. 


Se Se SE OSE OSE 


output log_tcpdump: tcpdump.log 


database: log to a variety of databases 


Se Se 


See the README.database file for more information about configuring 
and using this plugin. 


output database: log, mysql, user=root password=test dbname=db host=localhost 
output database: alert, postgresql, user=snort dbname=snort 

output database: log, unixodbc, user=snort dbname=snort 

output database: log, mssql, dbname=snort user=snort password=test 


Se OSE OSE SHE OE SHEE 


xml: xml logging 


See the README.xml file for more information about configuring 
and using this plugin. 


Se SE SR SHE HE SE 


output xml: log, file=/var/log/snortxml 


unified: Snort unified binary format alerting and logging 





The unified output plugin provides two new formats for logging 
and generating alerts from Snort, the "unified" format. The 
unified format is a straight binary format for logging data 

out of Snort that is designed to be fast and efficient. Used 
with barnyard (the new alert/log processor), most of the overhead 
for logging and alerting to various slow storage mechanisms 

such as databases or the network can now be avoided. 











Check out the spo_unified.h file for the data formats. 


Two arguments are supported. 
filename - base filename to write to (current time_t is appended) 
limit —- maximum size of spool file in MB (default: 128) 


output alert_unified: filename snort.alert, limit 128 
output log_unified: filename snort.log, limit 128 


Se SE OSE SE OSE SESE SEO SHE SHE SE SHE SHE SE HE SHE HE SE 


trap_snmp: SNMP alerting for Snort 


Se te 


Read the README.SNMP file for more information on enabling and using this 
plug-in. 


Se Se Se OSE 


#The trap_snmp plugin accepts the following notification options 
# [c],[p{mls]] 
# where, 

# c : Generate compact notifications. (Saves on bandwidth by 

# not reporting MOs for which values are unknown, not 

# available or, not applicable). By default this option is reset. 
# p : Generate a print of the invariant part of the offending packet. 
# This can be used to track the packet across the Internet. 

# By default this option is reset. 
# m_: Use the MD5 algorithm to generate the packet print. 
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By default this algorithm is used. 
s : Use the SHAl algorithm to generate the packet print. 


The trap_snmp plugin requires several parameters 
The parameters depend on the Snmpversion that is used (specified) 
For the SNMPv2c case the parameters will be as follows 
alert, <sensorID>, [NotificationOptions] , 
{trap|inform} -v <SnmpVersion> -p <portNumber> <hostName> <community> 


For SNMPv2c traps with MD5 digest based packetPrint generation 
output trap_snmp: alert, 7, cpm, trap -v 2c myTrapListener myCommunity 
For SNMPv2c informs with the 'compact' notification option 


output trap_snmp: alert, 7, c, inform -v 2c myTrapListener myCommunity 


For SNMPv3 traps with 
security name = snortUser 
security level = authentication and privacy 
authentication parameters 
authentication protocol = SHA , 
authentication pass phrase = SnortAuthPassword 
privacy (encryption) parameters 
privacy protocol = DES, 
privacy pass phrase = SnortPrivPassword 


Se Se SE OSE OSE OSH OSE OSE SHE SESE SEE SE SHE SE SHE SHE SE SHE SE SE SHE SE HE SHE HE HE 





#output trap_snmp: alert, 7, trap -v 3 -u snortUser -1l authPriv -a SHA -A SnortAuthPassword -x D 
myTrapListener 

#For SNMPv3 informs with authentication and encryption 

#output trap_snmp: alert, 7, inform -v 3 -u snortUser -l authPriv -a SHA -A SnortAuthPassword -x 
myTrapListener 


You can optionally define new rule types and associate one or 
more output plugins specifically to that type. 


This example will create a type that will log to just tcpdump. 
ruletype suspicious 
{ 

type log 

output log_tcpdump: suspicious.log 


} 


EXAMPLE RULE FOR SUSPICIOUS RULETYPE: 
suspicious SHOME_NET any -—> SHOME_NET 6667 (msg:"Internal IRC Server"; ) 


This example will create a rule type that will log to syslog 
and a mysql database. 
ruletype redalert 
{ 
type alert 
output alert_syslog: LOG_AUTH LOG_ALERT 
output database: log, mysql, user=snort dbname=snort host=localhost 


} 


EXAMPLE RULE FOR REDALERT RULETYPE 
redalert $HOME_NET any -> SEXTERNAL_NET 31337 (msg:"Someone is being LEET"; \ 
flags:A+;) 





# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 
# 


# 
# Include classification & priority settings 
# 


include classification.config 


# 
# Include reference systems 
# 
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lude reference.config 
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Te ee ee ee ee 
Step #4: Customize your rule set 


Up to date snort rules are available at http://www.snort.org 


The snort web site has documentation about how to write your own 
custom snort rules. 


The rules included with this distribution generate alerts based on 
on suspicious activity. Depending on your network environment, your 
security policies, and what you consider to be suspicious, some of 
these rules may either generate false positives ore may be detecting 
activity you consider to be acceptable; therefore, you are 
encouraged to comment out rules that are not applicable in your 
environment. 





Note that using all of the rules at the same time may lead to 
serious packet loss on slower machines. YMMV, use with caution, 
standard disclaimers apply. :) 


The following individuals contributed many of rules in this 
distribution. 


Credits: 
Ron Gula <rgula@securitywizards.com> of Network Security Wizards 
Max Vision <vision@whitehats.com> 
Martin Markgraf <martin@mail.du.gtn.com> 
Fyodor Yarochkin <fygrave@tigerteam.net> 
Nick Rogness <nick@rapidnet.com> 
Jim Forster <jforster@rapidnet.com> 
Scott McIntyre <scott@whoi.edu> 
Tom Vandepoel <Tom.Vandepoel@ubizen.com> 
Brian Caswell <bmc@snort.org> 
Zeno <admin@cgisecurity.com> 
Ryan Russell <ryan@securityfocus.com> 








Include all relevant rulesets here 


Se Se SE OSE OSE SHES SHE SHE SESH SE SE SHE SE SHE SE SHE SHE SESE SE SHE SE HEHE SHEE SE SHE SE SE SHE SESE SESE HES 


# shellcode, policy, info, backdoor, and virus rulesets are 
# disabled by default. These require tuning and maintance. 






















# Please read the included specific file for more information. 
#include $ PATH/bad-traffic.rules 
#include $ PATH/exploit.rules 
#include $ _PATH/scan.rules 

#include §$ PATH/finger.rules 
#include $ _PATH/ftp.rules 

include $R /telnet.rules 
#include $ H/rpc.rules 

#include $ H/rservices.rules 
#include $ H/dos.rules 

#include $ H/ddos.rules 

#include $ H/dns.rules 

#include $ H/tftp.rules 

#include $RU H/web-cgi.rules 
#include $RU H/web-coldfusion.rules 
#include $RU H/web-iis.rules 
#include $RU H/web-frontpage.rules 
#include $RU H/web-misc.rules 
#include $RU H/web-client.rules 
#include S$RU H/web-php.rules 
#include $RULE_PATH/sql.rules 
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H/xll.rules 

H/icmp.rules 
H/netbios.rules 
H/misc.rules 
PATH/attack-responses.rules 
/oracle.rules 
PATH/mysql.rules 
PATH/snmp.rules 


#include $RU 
#include $RU 
#include $RU 
#include $RU 
#include $RULE 
#include SRULE_ 
#include S$RULE 
#include SRULE_ 
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PATH/smtp.rules 
PATH/imap.rules 
PATH/pop3.rules 


#include SRULE_ 
#include $RUL 
#include SRULE_ 


1 A os | 





H/nntp.rules 
H/other-ids.rules 
PATH/web-attacks.rules 
PATH/backdoor.rules 
_PATH/shellcode.rules 
/policy.rules 
_PATH/porn.rules 
PATH/info.rules 
_PATH/icmp-info.rules 
/icmp.rules 
H/virus.rules 
H/chat.rules 
H/multimedia.rules 
H/p2p.rules 
H/experimental.rules 
H/local.rules 


#include $RU 
#include $RU 
#include SRULE_ 
#include $RUL 
#include $RUL 
#include $RUL 
#include $RUL 
#include S$RULE 
#include $RUL 
include S$RULE_ 
#include $RU 
#include $RU 
#include $RU 
#include $RU 
#include $RU 
#include $RU 
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